home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 1186 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.8 KB
  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: chase@centerline.com (David Chase)
  3. Newsgroups: comp.programming.threads,comp.std.c++
  4. Subject: Re: Is STL MT-Safe?
  5. Date: 21 Apr 1996 15:33:41 GMT
  6. Organization: CenterLine Software
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <4lc3ii$17d@wcap.centerline.com>
  9. References: <4kmjvj$89t@usc.edu> <4l12rf$q11@galaxy.ucr.edu> <31753C02.58A6@ix.netcom.com> <4l8pud$3t8@galaxy.ucr.edu>
  10. NNTP-Posting-Host: taumet.eng.sun.com
  11. X-Nntp-Posting-Host: vajra
  12. Content-Length: 2988
  13. Originator: clamage@taumet
  14.  
  15. In article <4l8pud$3t8@galaxy.ucr.edu>, Tom Payne <thp@cs.ucr.edu> wrote:
  16. >Fixing the stantard so that signal handlers can read global data (with
  17. >appropriate qualifications on the significance of the result) would be
  18. >a significant help.  The complexity here is only in the wording of the
  19. >standard.  
  20.  
  21. Nope, there's appalling interactions with constructors and destructors.
  22.  
  23. >The second major need is to allow a signal to force an exception in
  24. >without the program polling for it.  Complexity is never "necessarily
  25. >a good thing," unless the benefits outweigh the costs.  The benefits
  26. >would be
  27. >
  28. >  *  lower latency exception responses to signals
  29. >
  30. >  *  elimination of the CPU overhead of polling
  31. >
  32. >  *  much simpler programming for such situation.
  33. >
  34. >The cost would be in the increased complexity of the implementation
  35. >and CPU overhead caused by the implementation.  In a thread on this
  36. >topic a couple months ago, David Chase gave an implementation strategy
  37. >based on range tables that seemed to involve no CPU overhead and whose
  38. >complexity seemed reasonable.
  39.  
  40. The DISPATCH has reasonable complexity.  Unfortunately, unless both
  41. the compiler and the language are engineered to provide abort/commit
  42. semantics for every single operation, you end up with unsafe portions
  43. of code -- if an exception is thrown in one of those portions of code,
  44. you're potentially hosed (as in, how inconsistent would you like your
  45. data structures to get?)  The destructor/constructor/automatic-object
  46. semantics already in place make this non-trivial.
  47.  
  48. Personally, I think this might be a cool thing, but it's a little late
  49. for that now (when I write code that I want to work, which is most of
  50. the time, I work in the abort-commit style -- either the operation
  51. succeeds, or it virtually/semantically does "nothing", leaving the
  52. data structures in a valid state.  Carried down to the load/store
  53. level, this can be a little much).  It would almost certainly require
  54. the addition of garbage collection to the language, else people would
  55. certainly lose their minds (and you could *never* be sure that your
  56. code was really leak-tight -- run-time leak detectors will merely tell
  57. you about a single run of a program, and these leaks will be
  58. timing-dependent).
  59.  
  60. And no, I'm not sure that any even slightly popular language does this
  61. right.  I haven't studied Ada's approach to this problem in detail, so
  62. they might have gotten it right.  I think their approach is to allow
  63. programmers to delimit critical sections during which interrupts are
  64. suspended (think about implementing that efficiently on your favorite
  65. machine for a minute).  Another approach is to allow the execution of
  66. roll-back code if an operation is interrupted, but then you've got to
  67. write the roll-back code.  I suspect that this is the most efficient
  68. route to take, but it is really non-trivial at the programmer level
  69. (compilers can do this with stack frames, but compilers are very
  70. patient animals).
  71.  
  72. speaking for myself,
  73.  
  74. David Chase
  75.  
  76.  
  77.  
  78.  
  79.  
  80. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  81. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  82. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  83. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  84. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  85.